A storage system, such as a file server, is a special-purpose computer that provides file services relating to the organization of information on storage devices, such as hard disks. A file server (“filer”) includes a storage operating system that implements a file system to logically organize the information as a hierarchical structure of directories and files on the disks. Each “on-disk” file may be implemented as a set of data structures, e.g., disk blocks, configured to store information. A directory, on the other hand, may be implemented as a specially formatted file in which information about other files and directories are stored. An example of a file system that is configured to operate on a filer is the Write Anywhere File Layout (WAFL™) file system available from Network Appliance, Inc., Sunnyvale, Calif.
As used herein, the term “storage operating system” generally refers to the computer-executable code operable on a storage system that implements file system semantics and manages data access. In this sense the Data ONTAP™ storage operating system with its WAFL file system, available from Network Appliance, Inc., is an example of such a storage operating system implemented as a microkernel. The storage operating system can also be implemented as an application program operating over a general-purpose operating system, such as UNIX® or Windows NT®, or as a general-purpose operating system with configurable functionality, which is configured for storage applications as described herein.
A filer cluster is organized to include two or more filers and two or more storage “volumes” that comprise a cluster of physical storage disks, defining an overall logical arrangement of storage space. Currently available filer implementations can serve a large number of volumes. Each volume is generally associated with its own file system. The disks within a volume/file system are typically organized as one or more groups of Redundant Array of Independent (or Inexpensive) Disks (RAID). RAID 4 implementations enhance the reliability/integrity of data storage through the redundant writing of data “stripes” across a given number of physical disks in the RAID group, and the appropriate caching of parity information with respect to the striped data. In the example of a WAFL-based file system, a RAID 4 implementation is advantageously employed and is preferred. This implementation specifically entails the striping of data bits across a group of disks, and separate parity caching within a selected disk of the RAID group.
It is advantageous for the services and data provided by a storage system to be available for access to the greatest degree possible. Accordingly, some computer storage systems provide a plurality of filers in a cluster, with the property that when a first filer fails, a second filer is available to takeover and provide the services and the data otherwise provided by the first filer. The second filer provides these services and data by a “takeover” of resources otherwise managed by the failed first filer.
When two filers in a cluster provide backup for each other it is important that the filers be able to reliably detect failure(s) in their operations and to handle any required takeover operations. It would be advantageous for this to occur without either of the two filers interfering with proper operation of the other filer. To implement these operations each filer has a number of modules that monitor different aspects of its operations. A failover monitor is also used to gather information from the individual modules and determine the operational health of the portion of the filer that is being monitored by each module. All the gathered information is preferably stored in persistent memory, such as a non-volatile random access memory (NVRAM), of both the filer in which the monitor and modules are located, and in the NVRAM of the partner filer. The gathered information is “mirrored” on the partner's NVRAM by sending the information over a dedicated, high-speed, communication channel or “cluster interconnect” (e.g. Fibre Channel) between the filers.
Upon takeover of a failed filer, the partner filer asserts disk reservations to take over responsibility of the disks of the failed filer, and then sends a series of “please die” commands to the failed filer. After a takeover by a partner filer from a failed filer, the partner handles both file service requests that have normally been routed to it from clients plus file service requests that had previously been handled by the failed filer and that are now routed to the partner.
Subsequently, after correction of the failure, the “failed” filer is rebooted and resumes normal operation. That is, after the problem that caused filer failure has been cured, the failed filer is rebooted, returned to service, and file service requests are again routed to the rebooted filer. If there is a problem with the failed filer that prevents it from being rebooted, or there is a problem with other equipment to which with the failed filer is connected that prevent the rebooted filer from going back online and handling file service requests, the filer remains offline until the other problems are repaired.
With the takeover described above, the failed filer does not shut down “cleanly” and all services of the failed filer are not terminated in an orderly fashion. This includes terminating client connections to the failed filer without completing existing service requests thereto. In addition, there is usually some data remaining in the NVRAM of the failed filer that is “not flushed” and stored to hard disk, and the partner has to re-execute access requests of the failed filer. This can adversely impact system performance.